Serial No.: 10/713,872 

Amendment dated: March 31, 2008 

Response to Office Action mailed January 28, 2008 

REMARKS/ ARGUMENTS 

Claims 2, 4-5, 10, 12, 15 and 17-24 are pending in this application. Claims 2, 4-5, 10, 
12, 15 and 17-24 have been rejected. 

In view of foregoing amendments and following remarks, the Applicants respectfully 
request allowance of the Application. 
Claim Rejections under 35 U.S.C. §112 
§ 112, Second Paragraph 

Claims 2, 4-5, 10, 12, 15 and 17-24 are rejected under 35 U.S.C. § 112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 

Applicants respectfully submit claim 17 is definite, and note that the application 
framework and the application object repository framework are both modeled by a multi-layer 
modeling architecture. As the Specification notes on at least page 4, lines 10-13, the 
application object repository is structured as a function of application framework metadata, and 
the language for describing application framework describes the underlying constructs of the 
repository framework. Thus, claim 17 first includes a limitation setting forth the layers of a 
multi-layer modeling architecture with respect to an application framework supporting an 
application, and then includes a limitation setting forth the layers of the same multi-layer 
modeling architecture with respect to the application object repository which serves to store 
application framework metadata and is structured as a function of the application framework. 

It should be clear from the antecedent bases of the various modeling layers that a 
common modeling language occupying the third layer of the multi-layer modeling architecture 
defines both the application framework and a repository framework model containing repository 
constructs and semantics. The application framework and the repository framework model both 
occupy the second level of the multi-layer modeling architecture. Application framework 
metadata (representing application framework extensions) and an application object repository 
framework both occupy a first layer in the modeling architecture. In this respect, as Figs. 2 and 
3a-c and their corresponding description in the Specification note, the application framework 
metadata (occupying the first layer) can be used to generate the application object repository. 

Further, in response to the Examiner's assertions that there is no disclosure of how each 
modeling layer is defined with proper association to the entities "application framework", 
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"application framework metadata", "repository framework model", and "application object 
repository framework", Applicants respectfully direct the Examiner to Figs. 2 and 3a-c and their 
corresponding descriptions in the Specification starting at page 6 and continuing through page 
10. In particular, Applicants point out the Specification clearly notes there is a relationship 
between the meta-model for the application framework and the meta-model for the repository. 
Specification, p. 9, lines 19-21. Further, Applicants note that FIG. 2 illustrates how application 
framework metadata 215(2) is used by a repository generator 705 to generate repository 
framework 205, including repository schema metadata and repository runtime metadata. In 
light of Fig. 2, its accompanying description in the Specification, and the Specification as a 
whole, one of ordinary skill in the art would understand the metes and bounds of the invention, 
including how application framework metadata is used to generate a repository framework. 

Accordingly, Applicants respectfully submit claim 17 is definite. Applicants respectfully 
request the § 112, second paragraph rejection be withdrawn. Claims 2, 4-5, 10, 12, 15, and 
18-24 are also definite as they include similar limitations as claim 17. Accordingly, Applicants 
respectfully request the § 112, second paragraph rejection be withdrawn for these claims. 
§ 112, First Paragraph 

Claims 2, 4-5, 10, 12, 15 and 17-24 are rejected under 35 U.S.C. § 112, first paragraph, 
as failing to comply with the enablement requirement. 

Applicants respectfully submit claim 17 is enabled by the Specification. For instance, 
Applicants note Figs. 3a-c identify which layers are associated with which "entities" (as the 
Examiner has termed, for example, application framework metadata, application framework, 
common modeling language). Contrary to the Examiner's assertions, the layer-pertinent actions 
(e.g., defining, generating, modeling) are adequately enabled with respect to which layers the 
actions pertain. For instance, Fig. 7 clearly illustrates that application framework metadata is 
compliant with a repository framework compliant modeling language and a common modeling 
language, and that the application framework metadata is used by a repository generator to 
generate application object repository. When Fig. 7 is viewed with respect to Figs. 3a-c (along 
with their respective descriptions in the Specification), one of ordinary skill in the art clearly can 
understand (1) the correlation between the various layers and entities, and (2) how the various 
actions claimed in the claim 17 correspond to the entities and the layers in the multi-layer 
modeling architecture. Applicants have scoured the MPEP and can find no provision that 
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requires the Specification to contain "a single clear and substantially complete portion" of the 
Specification that illustrates complete support for a claim, as the Examiner indicates is required 
for claim 17 to be enabled. See Office Action of January 28, 2008, p. 6. Thus, Applicants 
respectfully submit that claim 17 is clearly enabled when the Specification is read as a whole. 

Accordingly, Applicants respectfully request the § 112, first paragraph rejection be 
withdrawn. As the Examiner has based the § 112, first paragraph rejection for claims 2, 4-5, 10, 
12, 15, and 18-24 on the same reasons as claim 17, Applicants respectfully submit these claims 
are also enabled. Applicants respectfully request the § 112, first paragraph rejection of these 
claims be withdrawn as well. 

CLAIMS 2. 4-5. 10. 12. 15. AND 17-24 DEFINE OVER IYENGAR 

Claims 2, 4-5, 10, 12, 15 and 17-24 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Iyengar, U.S. Pat. No. 6,874,146 (hereinafter "Iyengar"). 
For the reasons set forth below, the pending claims are not rendered obvious by Iyengar. 

Representative claim 17 recites in part: 

responsive to new application framework extensions, generating an application 
object repository supported by the application object repository framework and 
conforming to the application framework with the new application framework 
extensions, comprising: 

generating application framework metadata representing the 
application framework with the new application framework extensions, 

and occupying the first layer in the multi-layer modeling architecture as meta- 
model data, wherein the new application framework metadata is 
generated using the repository constructs defined by the repository 
framework model \r\ the second layer; 

upon said generating, validating the generated meta-model data 
with respect to the repository framework model constructs; 

Iyengar fails to disclose this subject matter. The pending claims are directed to 
generation of an application object repository to store application development objects. The 
application object repository is generated in response to each time an application framework 
upon which the repository is based is modified through new application framework extensions 
or changes to the application framework. In order for the repository to take advantage of the 
additional functionality created by the extensions or changes, the repository is re-generated and 
an existing application development objects are migrated to the generated repository. 
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Iyengar, on the other hand, generally concerns the integration of Unified Modeling 
Language ("UML"), Meta Object Facility ("MOF") Modeling, and XML to permit stream-based 
interchange of metadata, thereby allowing metadata to be transferred between UML- and MOF- 
based models and metamodels. Applicants reiterate their argument that Iyengar, however, 
does not disclose the actual generation of repositories. 

More specifically, Iyengar does not disclose generation of metadata of one metamodel 
{i.e., the application framework including application framework extensions) using the 
constructs of a different metamodel {i.e., the repository framework), where both the repository 
framework and application framework are defined by a common meta-metamodel. The Office 
Action cites generally to Figs. 3 of Iyengar and Figs. 1, and 3b-c of Iyengar, USP 6,038,393 
(hereinafter "the Iyengar ( 393 patent") which is incorporated by reference into Iyengar, as 
disclosing this particular limitation. However, these figures do not disclose this limitation; rather, 
Fig. 3 discloses the use of an XMI module that receives a UML metamodel, MOF metamodel 
definitions, and XML syntax and encoding, and produces UML and MOF DTD and XML data 
streams, as well as Common Warehouse Metadata ("CWM") DTDs and streams and CORBA DTD 
and XML streams. While the XMI module may produce DTDs and documents related to 
different modeling schemes, Iyengar fails to disclose the generation of application 
metadata representing an application framework based on the repository constructs of a 
repository framework model. 

Moreover, the Iyengar '393 patent also fails to disclose the generation of metadata 
representing an application framework based on the repository constructs of a repository 
framework model. In particular, the figures cited by the Office Action merely disclose that 
legacy items are transformed to corresponding UML models before being stored in a repository, 
and that UML is based on a set of object classes defined and stored in the repository. However, 
there is absolutely no disclosure in the Iyengar '393 patent that the UML itself is the standard 
by which the repository is modeled. In other words, the Iyengar 393 patent fails to teach that 
the repository is modeled using UML, as claim 17 requires. Rather, all that is stated by the 
Iyengar 393 patent is that the repository itself stores a set of classes used to transform legacy 
items into UML models. 

Applicants also maintain their argument that Iyengar fails to disclose validation of the 
generated metadata against the constructs from which the metadata was generated, as recited 
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in the pending claims. The Office Action asserts that such a limitation is disclosed in Col. 9, line 
40 to Col. 10, line 19 and Col. 10, lines 41 and 42. See Office Action of January 28, 2008, p. 8. 
The Office Action further asserts in response to Applicants' previous arguments that "where 
metadata is retrieved 'from one repository in order to provide basis for mapping against model- 
based constructs of a target business flow, the validating of XML against the model construct is 
integral to any metadata-based modeling." Office Action of January 28, 2008, p. 23 (emphasis 
added). Applicants respectfully note that the assertion in the Office Action in response to the 
Applicants' previous argument is irrelevant. The Office Action is describing a different situation 
for allegedly requiring metadata validation. Claim 17 recites that upon said generating, the 
generated metadata is validated. As a result, whether metadata retrieved from a repository is 
validated is irrelevant with respect to claim 17. 

Instead, to maintain a proper rejection of claim 17, the Office Action must show a 
teaching or suggestion in Iyengar that metadata is validated after it is generated. However, the 
cited portions of Iyengar fail to disclose any mention of or reference to metadata validation 
upon generation of metadata. Rather, the cited portions only generally discuss the 
properties of MOF, and in particular MOF-based metadata and MOF models. While Iyengar 
discusses how MOF metadata belonging to a MOF model must conform to rules governing the 
model's structure and consistency, there is no inherent or explicit disclosure of validating 
generated metadata against the constructs of the model from which it was generated after the 
metadata is generated. 

Thus, for at least all of the reasons set forth above, Applicants respectfully submit 
Iyengar does not render representative independent claim 17 obvious under 35 U.S.C. § 103. 
As independent claims 18-21 contain similar limitations, claims 18-21 also are not rendered 
obvious under § 103. Further, as claims 2, 4-5, 10, 12, 15, and 22-24 depend from allowable 
independent claims 17-21, Applicants respectfully submit these claims also are not rendered 
obvious under § 103. Accordingly, reconsideration and withdrawal of the rejection to claims 2, 
4-5, 10, 12, 15, and 17-24 under 35 U.S.C. § 103 are respectfully requested. 
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CONCLUSION 

Applicants respectfully submit all outstanding rejections have been overcome. It is 
respectfully submitted that, in view of the foregoing amendments and remarks, the application 
is in clear condition for allowance. Issuance of a Notice of Allowance is earnestly solicited. 

Although not believed necessary, the Office is hereby authorized to charge any fees 
required under 37 C.F.R. § 1.16 or § 1.17 or credit any overpayments to Deposit Account No. 
11-0600. 

The Office is invited to contact the undersigned at 202-220-4200 to discuss any matter 
regarding this application. 

Respectfully submitted, 
KENYON & KENYON LLP 



Date: March 31. 2008 /Mark D. Yuan/ 

(Registration No.: 57,312) 

Kenyon & Kenyon LLP 

333 West San Carlos Street, Suite 600 

San Jose, CA 95110 

Telephone: (408) 975-7500 
Facsimile: (408) 975-7501 
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